^A^DGENERAL PROGRAMMING TIPS^E
This is a modification   of an excellent  ^Darticle by Peter Hartzler
which appeared in the June AWAUG  ^E (Wash.DC area) newsletter.   I
particularly liked this article as I feel not enough is being written for
the beginning programmer and this article gives an excellent approach to
some of the problems involved.  I have modified it slightly to attempt to
save space & to give explanations as to what each line actually does.
We have this newsletter available in our newsletter library and suggest
you read the actual article also.  It is very good article.

A good first step in program writing is to WRITE down exactly what you
want the program to do, including: what data will be used, where it will
come from, what the output will be, and how ADAM will arrive at it's
results.  This can be very difficult but once you have this much, the
rest of the program design will be easy.

Take  a program which takes two numbers from the operator, and divides
the first by the second, and then displays the answer. Also remembering
that if the second number is zero (division by zero), then the program
should display a message such as "ILLEGAL DENOMINATOR", and recycle to
the beginning for another try.
AT THIS POINT, WHY DON'T YOU TRY TO WRITE SUCH A PROGRAM BEFORE FINISHING
THIS ARTICLE.

^DPeter Hartzler^E continues that once you have decided just what  you
want the program to do, your next step is to design the structure of the
program, wlhich means setting down what the machine will do first, next,
etc. until it complete's its run of the program.  If your program uses
many branches orloops you may find flow charts to be an aid.  Another
approach is to write out the program structure in outline form (this is
also called pseudocode).

START
GET NUMERATOR
GET DENOMINATOR
   IF DENOMINATOR = 0
        DISPLAY "ILLEGAL DENOMINATOR"
        GO TO START
   ELSE
        COMPUTE RESUT =
             NUMERATOR/DENOMINATOR
   END IF
DISPLAY RESULT
END:

You may go through several revisions before you are finished with the
preliminary program design.  Also when you go back and modify your
program you can use the design as a reference to see just where you need
to make what changes.

As you design the program, look for operations which you need to do more
than once.  Rather than writing these out each time you need them, you
can save a lot of trouble by writing the routine once and calling it
(GOSUB in basic) from the places you need it.  This will save time and
better if there is an error in a subroutine, one set of changes will be
all that is needed, rather than changing it throughout the program for
each repetition of that operation.

The strategy of using a section of code more than once, as a subroutine
is key to the concept of modular programming.  It also makes debugging
programs a lot easier.

Peter Hartzler then gives these thoughts on variable names.  There is
really no excuse for using only single letters for variable lnames.  Most
interpreters allow quite a few characters in a variable name (smartbasic
does), and you should take advantage of this.  If you write code which
has lots of x's, y's and z's and other sorts of alphabet soup, it may run
fine but is very hard to read, especially after it has set on the shelf
for awhile and you forgot what "q" represents.  Avoid cryptic variable
names.

Smart Basic allows long variable names, but ONLY looks at the first two
characters to decide what variable it is (not counting subscripts). So,
NU is equivalent to NUMERATOR and/or NUMBER for SmartBasic purposes.
Watch out for this but make your vairable names readable (plain english
variable names are easier to remember & use, especially if you are
working on a program longer than one screen).

Our (Peter's) little program might come out looking like this.

00 REM THIS PROGRAM TAKES TWO NUMBERS AND DIVIDES THE FIRST BY THE SECOND
10 REM START
20 INPUT "Numerator?   "; NUMERATOR
30 INPUT "Denuminator? "; DENOMINATOR
40 IF DENOMINATOR = 0 THEN PRINT "ILLEGAL DENOMINATOR": GOTO 10: REM
START.
50 RESULT = NUMBERATOR/ DENOMINATOR
60 PRINT NUMBERATOR; " ? "; DENOMINATOR; " = "; RESULT
99 END.

While this example may seem trivial, it is the first embrionic skeleton
of a full blown calculator, or even a spread sheet program.  You have to
start somewhere, and you have to plan ahead.   This is also a good simple
example for beginners which will show them the steps necessary to go from
an idea to a program to carry out that idea.

Peter Hartzier continues, indicating that it is a good idea to embed
little messages (or REM statements) in your program telling yourself what
you are doing at a particular point in the program.  This is a great help
when you later go back to a program and try to figure out why you wrote
it that why or how it actually works.   Also if you are writing this for
someone else it will allow them to follow your thought process and will
make it easier for them to modify or customize for their own purposes.

The who purpose of computer languages (such as Basic) is to make it
possible for humans to read the instructions in something approaching
Enlgish.  To this end it is worthwhile to use self explanitory variable
names, include comments to explain what you're doing, and use subroutines
to centralize specific operations.

Besides summarizing and modifying the above article of Peter Hartzier
slightly, I have had the following explanation:

LINE EXPLANATIONS.
00 REM is a REM(ark) or note to yourself & does not have any actual
effect on the program.

10 Also a REM statement

20 INPUT whens ADAM is waiting for you to input or type in some
information.   The word(s) in the "s after Input are printed to the
screen so you have an idea what ADAM is asking you to input, in this case
Numerator. The ; NUMERATOR means that from now on whatever value was
input will be called NUMERATOR for the purposes of this program and
whever the program asks for NUMERATOR, the actual value previously typed
in by you as an input will be used.

30 (Same as 20 but for Denominator).

40 The IF means exactly that IF the following is true, then do what is
indicated.  IF the following was not true, then this line would not be
used in the program but skipped over. This line only comes into use IF
the condition specified is true.
Here IF the (value input for ) denominator is 0, the the program prints
to the screen "ILLEGAL DENOMINATOR". Next this line 40 has GOTO 10, this
sends the program back to line l0 and it reruns from that point. The REM
start, is merely to tell us why it is going back to line l0 or what line
l0 actually did.

50 We are creating another variable which is called RESULT and we are
setting result equal to NUMERATOR/DENOMINATOR  (numerator divided by
denominator).

60 Prints to the screen the value for NUMERATOR which we previously input
, then what is in the "s (which is /), then the value we previously input
for DENOMINATOR, then what is in the next set of "s (which is =) and
finally the value which ADAM calculated in line 50 for Result.
99 END, ends the program at this point.
This program could be modified so that lines  after line 60 and before
line 99 asked if we wished to calculate another division and then if the
answer was Yes, send the program back to line l0 and if the answer will
other than yes, allow the program to go to line 99 and end.
Such lines  could be as follows:
70 INPUT "DO YOU WANT TO CONTINUE?    Y OR N "; answer$
[Line 70 has ADAM ask you if you want to continue and then wait for your
answer.  Your answer will now become the variable answer$.  The $ is
necessary as we are dealing with words or letters and not numbers at this
point]

80 IF answer$ = "Y" or if answer$ = "y" THEN GOTO 10.

Line 80 has ADAM see if your answer was Y or y and if it was it sends the
program back to line l0 to repeat or continue.
If the answer was NOT Y or y  then the program continues to line 99 and
ends.
Since some people may not have been using capital letters, the or
statement was necessary to cover an input of y instead of Y.

Try playing around with this program.  Can you think how the use of HOME
to clear the screen might improve the program at some point ?   Can you
think of how the use of a delay routine such as FOR X = 1 to 1000 : NEXT
X might improve the program at some point ?   Try adding these features
to the program.
Again I want to thank Peter Hartzier and AWAUG (June 89 issue) for this
excellent article on Programming tips and the step by step writing of a
simple program.
^B


